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Abstract 

The  Fithtpear  priority  queue  algorithm  it  pretented 
and  analyzed.  Fithtpear  maket  fewer  than  80 %  at 
many  comparitont  at  heaps  in  the  wortt  cate,  and  ill 
relative  performance  it  even  better  in  many  common 
tituationi.  The  code  itself  embodiet  an  unutual  recur¬ 
sive  structure  which  permits  highly  dynamic  and  data- 
dependent  execution.  Fithtpear  alto  differs  from  heaps 
in  that  it  can  be  implemented  efficiently  u ting  sequen¬ 
tial  storage  such  at  stacks  or  tapes,  making  it  possibly 
attractive  for  implementation  of  very  large  queues  on 
paged  memory  system. t.  (Details  of  the  implementation 
are  deferred  to  the  full  paper.) 

1  Introduction 

A  priority  queue  is  an  abstract  data  type  consisting 
of  a  finite  multiset  P  over  a  linearly  ordered  universe 
D  together  with  the  following  operations: 

MAKEEMPTY:  Sets  P  :=  0. 

EMPTY? :  Returns  true  if  P  =  0,  false  otherwise. 

INSERT(z):  Sets  P  :=  Pu  {*}. 

DELETE  -MIN :  Sets  P  :=  P  -  {y}  and  returns  y,  where 
y  is  a  least  element  in  P. 

Priority  queues  find  application  in  discrete  event  simu¬ 
lation,  computational  geometry,  shortest  path  compu¬ 
tations,  and  many  other  areas  of  computer  science. 

A  simple  implementation  of  priority  queues  keeps  the 
elements  in  an  ordered  list.  Insertions  are  performed 
by  binary  search  and  take  flog  h]  comparisons  to  yield 
a  list  of  size  A,  and  the  remaining  operations  take  no 

?Thi*  work  was  supported  ia  part  by  the  Office  of  Naval  Re¬ 
search  under  Contract  N00014-82-K-01S4,  and  by  the  National 
Science  Foundation  under  Grant  MCS-81 16678. 
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comparisons.1  However,  the  time  per  insertion  is  0(A), 
making  the  algorithm  unattractive  in  practice  for  all 
but  very  small  queues. 

The  heap  [l|  is  a  standard  data  structure  for  imple¬ 
menting  priority  queues  which,  like  the  ordered  list, 
uses  Oflog  A)  comparisons  per  operation,  but  the  time 
per  operation  is  linear  in  the  number  of  comparisons 
and  so  is  also  O(logA).  Indeed,  heaps  are  so  common 
as  to  be  often  identified  with  the  abstract  data  type 
which  they  implement.  So  there  is  no  confusion,  by  a 
“heap”  we  mean  a  balanced  binary  tree  with  elements 
z,  labelling  each  node  i  such  that  for  any  nodes  »',  j,  if 
•  is  an  ancestor  of  j,  then  x,  <  x}. 

One  of  the  first  applications  of  heaps  was  to  an  algo¬ 
rithm  for  sorting  n  items  using  0(n  logn)  comparisons 
[5|.  Since  D(n  logn)  is  a  lower  bound  on  the  number  of 
comparisons  for  sorting,  it  follows  that  the  amortized 
cost2  of  a  priority  queue  operation  is  R(logn)  in  the 
worst  case,  where  n  is  the  length  of  the  operation  se¬ 
quence.  Since  heaps  achieve  this  bound,  they  are  in 
some  sense  optimal. 

Another  intriguing  property  of  heaps  is  that  they  ex¬ 
ploit  the  ability  to  randomly  access  memory.  The  pat¬ 
tern  of  memory  accesses  is  dynamically  determined  by 
the  data,  and  there  is  no  apparent  way  of  implementing 
heaps  while  maintaining  the  logarithmic  amortized  op¬ 
eration  cost  on  more  restrictive  types  of  memory  such 
as  tapes  or  stacks. 

Other  data  structures  such  as  2-3  trees,  etc.  can 
also  implement  priority  queues  with  similar  complexity 
bounds,  but  all  require  random  access  storage.  Thus, 
priority  queues  have  seemed  to  be  an  example  of  an 
abstract  data  type  whose  efficient  implementation  re¬ 
quired  random  access  storage,  and  heaps  are  a  simple 
implementation  which  seemed  optimal. 

In  this  paper,  we  show  that  both  intuitions  are  wrong 

'All  logarithms  in  taken  to  the  base  2  unless  specified 
otherwise. 

3Th«  sms  rifted  cost  of  a  sequence  of  operations  is  the  total  cost 
of  the  sequence  divided  by  the  number  of  operations  |S),  [4). 


by  presenting  a  new  priority  queue  algorithm,  Fishs¬ 
pear,  which  can  be  implemented  with  sequential  stor¬ 
age  (using  a  fixed  number  of  pushdown  stacks),  and 
which  is  more  efficient  than  heaps  in  two  senses  which 
are  made  more  precise  in  the  next  section.  First  of 
all,  it  has  similar  amortized  efficiency  to  heaps  in  the 
worst  case  (0(log  n)  comparisons  per  queue  operation), 
but  the  coefficient  of  logn  is  actually  less  (1.2  versus 
1.5)  on  sequences  that  start  and  end  with  the  queue 
empty.  Secondly,  the  number  of  comparisons  is  “little- 
oh"  of  the  number  made  by  heaps  for  many  classes  of 
input  sequences  that  are  likely  to  occur  in  practice. 
For  example,  if  the  queue  builds  to  a  certain  size  A 
and  then  receives  alternately  a  very  large  number  of 
INSERT  and  DELETE -MIN  operations,  where  the  ele¬ 
ments  to  be  inserted  are  drawn  randomly  with  uniform 
distribution  from  the  unit  interval,  then  the  amortized 
number  of  comparisons  made  by  heaps  for  each  such 
pair  is  about  3  log  A  (log  ft  for  the  INSERT  and  2  log  A 
for  the  DELETE  .MIN ),  whereas  the  amortized  cost  for 
Fishspear  is  0(1).  (The  queue  at  any  time  during  this 
procedure  contains  the  A  largest  elements  ever  inserted; 
hence,  the  size  of  the  smallest  of  these  approaches  1,  so 
the  probability  that  a  newly-inserted  element  will  be 
deleted  by  the  very  next  operation  also  approaches  1. 
Fishspear  is  particularly  efficient  in  this  situation.) 

More  generally,  the  number  of  comparisons  required 
by  Fishspear  depends  only  on  the  size  of  the  “active” 
part  of  the  queue,  not  on  the  overall  size.  In  the  above 
example,  the  active  part  shrinks  over  time  as  the  queue 
fills  with  larger  and  larger  elements.  This  notion  is 
quantified  more  precisely  in  the  next  section. 

Fishspear  can  be  implemented  using  sequential  stor¬ 
age  such  as  tapes  or  stacks  so  that  the  overall  run  time 
is  proportional  to  the  total  number  of  comparisons.3 
Sequential  storage  algorithms  such  as  Fishspear  are 
attractive  on  typical  paged  computer  systems  since 
they  tend  to  exhibit  better  paging  performance  than 
truly  random-access  algorithms  such  as  heaps.  This, 
together  with  the  better  behavior  on  common  but  re¬ 
stricted  classes  of  operation  sequences,  could  make 
Fishspear  an  attractive  alternative  to  heaps  in  certain 
practical  situations.  We  hope  eventually  to  obtain  ex¬ 
perimental  data  to  support  such  a  claim. 

The  principal  disadvantages  of  Fishspear  are  that  it 
is  more  complicated  to  implement  than  heaps,  and  the 
overhead  per  comparison  is  greater. 

Fishspear  is  similar  to  self-adjusting  heaps  (3|  in  that 
the  behavior  depends  dynamically  on  the  data  and  the 
cost  per  operation  is  low  only  in  the  amortized  sense — 
individual  operations  can  take  time  fl(n)  even  though 

^Details  are  deferred  to  the  full  paper. 


that  occurs  only  rarely.  Important  differences  are  that 
self-adjusting  heaps  support  an  additional  operation, 
MELD,  which  Fishspear  does  not,  but  Fishspear  does 
not  require  random  access  storage.  We  do  not  know 
the  relative  performance  of  the  two  algorithms  on  re¬ 
stricted  classes  of  operation  sequences. 

2  Performance  Bounds 

We  now  look  in  some  detail  at  how  to  measure  the 
performance  of  priority  queue  algorithms. 

The  speed  of  sorting  algorithms,  for  example,  is  often 
expressed  in  terms  of  the  worst-case  or  average  num¬ 
bers  of  comparisons  used  in  sorting  n  input  elements. 
They  are  useful  expressions  in  that  context  since  in 
many  applications  it  is  reasonable  to  assume  that  all 
initial  orderings  of  the  inputs  are  about  equally  prob¬ 
able  and  thus  the  parameter  n  provides  an  adequate 
description  of  the  problem.  We  need  the  further  as¬ 
surance  that  the  running  time  can  be  closely  related 
to  the  number  of  comparisons  made  so  that  the  more 
combinatorial  analysis  of  the  number  of  comparisons 
yields  results  on  program  performance. 

The  case  of  priority  queues  presents  no  such  sin¬ 
gle  natural  parameter.  The  total  number  of  INSERT 
and  DELETE-M1N  operations  performed  is  one  possi¬ 
ble  measure  but  in  many  applications  the  maximum 
length  of  the  queue  attained  is  expected  to  be  far  less 
than  the  total  number  of  elements  inserted.  We  require 
a  measure  more  sensitive  to  the  demands  made  on  the 
priority  queue. 

A  performance  measure  we  shall  use  is  based  on  the 
sequence  h  =  At, . . . ,  A*  denoting  the  size  of  the  queue 
immediately  after  the  insertion  of  each  of  rt  elements.4 
The  sequence  h  is  called  the  tize  profile  for  that  run 
of  the  priority  queue,  where  by  run  we  shall  mean 
any  sequence  of  priority  queue  operations  for  which 
DELETE -MIN  is  never  applied  to  an  empty  queue  and 
the  queue  is  initially  and  finally  empty.  For  a  run  with 
size  profile  b,  the  usual  heap  implementation  may  use 
log  ft,  comparisons  at  the  jth  insertion  and  a  corre¬ 
sponding  2  log  ft,  comparisons  for  that  deletion  which 
subsequently  first  takes  the  queue  from  size  ft  down  to 
size  ft  -  I.  Hence  an  upper  bound  for  the  worst-case 
number  of  comparisons  is  approximately  3  £  log  ft,. 
The  comparisons  for  the  naive  list  implementation  are 
32  flog  A,].  As  a  lower  bound,  we  have 

Theorem  i  The  worst- caie  number  of  comparisons 
used  by  any  priority  queue  algorithm  on  runs  with  size 

4Her*  the  parameter  n  ie  the  Bomber  of  iaeertiooe,  oot  the  total 
length  of  the  operation  sequence. 


profile  hint  least 
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Proof:  Consider  all  possible  qnene  runs  with  size  pro¬ 
file  h  and  distinct  input  elements.  The  priority  queue 
algorithm  b  required  to  determine  the  unique  correct 
order  of  the  output  elements.  Elements  simultaneously 
in  the  queue  are  output  in  order,  so  each  possible  way 
of  inserting  a  new  element  into  the  queue  yields  a  dis¬ 
tinct  output  sequence.  There  are  Ay_i  + 1  =  h,  places 
where  the  /**  element  can  be  inserted  relative  to  the 
other  elements  in  the  queue  at  that  time,  and  each  of 
these  yields  a  different  output  order,  hence,  the  number 
of  runs  which  must  be  dbtingubhed  b  fl  Ay*  By  the 
usual  information-theoretic  argument,  any  algorithm 
requires  at  least  flog  FI  =  fX  log  Ayl  binary  com¬ 
parisons  to  dbtingubh  among  these  runs.  I 

Fix  a  run  and  let  x,  be  the  ttk  element  inserted  into 
the  queue.  Now  consider  any  element  y  in  the  queue 
at  a  particular  time.  It  will  be  convenient  to  associate 
with  each  such  y  a  dbtinct  i  such  that  y  =  z«.  If  the 
z,  are  all  dbtinct,  the  association  b  obvious,  but  since 
we  permit  the  queue  to  be  a  multiset,  there  may  be 
more  than  one  way  to  make  the  correspondence.  For 
definiteness,  if  the  queue  contains  k  copies  of  y  at  a 
particular  time  r,  we  associate  those  copies  with  the  k 
largest  elements  of  {•  <  nT  |  y  =  Xj},  where  nr  b  the 
number  of  INSERT  operations  up  to  time  r.  Implicit  in 
our  use  of  the  notation  “x,"  b  that  i  b  associated  with 
the  element  z,,  so  we  say  “z,  b  in  the  queue  at  time 
r”  to  mean  that  z,  b  contained  in  the  multiset  at  time 
r  and  b  associated  with  index  i. 

We  now  define  a  strong  total  ordering  -<  on  the  x,’s. 
z,  <  Xj  if  either  x,  <  x},  or  z,  =  x,  and  i  <  j.  By  the 
conventions  of  the  preceding  paragraph,  it  b  clear  that 
if  Xj  <  x j  and  Zj,x}  are  simultaneously  in  the  queue, 
then  z,  will  appear  as  output  before  xy. 

The  depth  of  x,  at  a  time  when  it  is  in  the  queue  b 
one  plus  the  number  of  elements  z;  <  z,  in  the  queue  at 
that  time.  There  are  several  applications  where  most 
of  the  elements  inserted  attain  only  a  relatively  shal¬ 
low  depth  during  their  residence  in  the  queue.  An  ex¬ 
ample  b  when  the  input  elements  are  drawn  from  a 
uniform  dbtribution  and  the  profile  remains  at  an  ap¬ 
proximately  constant  level  for  long  periods.  We  would 
like  to  take  advantage  of  such  behavior  with  an  al¬ 
gorithm  which  does  not  dbturb  the  deeper  elements 
unnecessarily. 

For  a  more  refined  analysb  of  complexities,  we  may 
define  the  met- depth  profile  m  for  a  run  as  the  se¬ 
quence  mi, m2 . where  m,  b  the  maximum  depth 


attained  in  the  queue  by  element  xy  during  the  run. 
While  the  usual  heap  implementations  appear  to  de¬ 
rive  no  advantage  when  m  <  h,  our  main  theorem 
shows  that  Fbhspear  requires  at  most 

m 

cX^logm,  +0(n) 

>=i 

comparisons  on  a  run  with  n  insertions  (and  n  dele¬ 
tions),  where  the  coefficient  c  b  less  than  2.4. 

Less  apparent  b  that  the  upper  bound  for  Fbhspear 
holds  even  if  “my"  b  replaced  by  “hy".  Indeed,  an 
individual  element  can  attain  depth  in  the  queue  much 
greater  than  the  size  of  the  queue  when  it  was  first 
inserted.  Nevertheless,  on  the  average,  the  m’s  are  no 
bigger  than  the  A’s. 

Theorem  3  Contider  a  priority  queue  run  with  max- 
depth  profile  m  and  size  profile  h.  There  exiete  a  per¬ 
mutation  t  tuch  that  for  all  i,  1  <  »  <  n. 

Proof:  Suppose  there  b  some  pair  i,j  with  •  <  j  and 
Zi  >•  Xj,  where  Xj,Xy  are  adjacent  in  the  total  order¬ 
ing  •<  of  all  the  elements.  We  consider  the  effect  of 
interchanging  xt  and  x,  in  the  run. 

If  Zi  leaves  the  queue  before  x}  enters,  thb  inter¬ 
change  does  not  affect  mi  or  my.  If  not,  let  M  be 
the  maximum  depth  attained  by  x<  before  xy  enters 
and  let  M'  and  M"  be  the  maximum  depths  attained 
by  Zi  and  xy  respectively  after  this  time.  Note  that 
M'  >  M".  Before  the  interchange, 

mi  =  max) A/,  A/'}  and  m,  =  M", 
while  after 

mi  =  max{Af,  M")  and  my  =  A  f. 

We  consider  two  cases  and  compare  the  pairs  (m,.  m,) 
before  and  after  the  interchange. 

1.  M  <  AT. 

Before:  (A/',  M").  After:  {max {A/. A/"}.  A/'). 

2.  M'  <  A f. 

Before:  After:  {A/,  A/'). 

In  each  case  the  pair,  regarded  as  a  multiset,  increases 
in  value  in  one  element  or  remains  the  same. 

We  can  repeat  thb  process  wherever  there  is  a  pair  of 
elements  with  adjacent  values  where  the  larger  value  is 
inserted  first.  The  final  result  will  be  a  “FIFO"  run  in 
which  the  elements  are  inserted  in  order  of  increasing 
value.  For  such  a  run,  m*  =  h,  since  the  initial  depth  of 
any  element,  which  will  be  hj  here,  cannot  be  increased 
by  subsequent  insertions.  Since  each  interchange  on 
the  way  to  constructing  the  ‘‘FIFO’'  run  could  only 
increase  the  values  of  {mt.mj,...}  as  a  multiset,  the 
result  follows  at  once.  I 


3  The  Fishspear  Algorithm 

The  algorithm  which  we  present  in  Section  3.2  is  an 
instance  of  a  general  class  of  (non-determinbtic)  algo* 
rithms  which  all  operate  on  the  same  data  structure 
called  a  flshspear.  The  correctness  of  such  algorithms 
is  fairly  easy  to  see.  What  is  not  obvious  is  that  there 
is  a  deterministic  rule  for  making  choices  that  leads  to 
good  behavior. 

3.1  Fishspear  Data  Structure 

The  Fishspear  data  structure  represents  a  priority 
queue  as  a  collection  of  sorted  lists  called  segments. 
The  collection  is  partially  ordered  by  the  rule  that 
V  <  V  iff  *  <  y  for  every  x  €  V  and  j  €  V.  A  k- 
barbed  fishspear  consists  of  (possibly  empty)  segments 

U,Wk . Wl  and  Vk . Vx.  Segments  U,Wk . Wx 

are  linearly  ordered  and  form  the  shaft  of  the  spear, 
that  is,  U  <  Wk  <  W*_j  <  ...  <  Wt.  Segments 

Vk . Vx  are  the  barbs  of  the  spear  and  satisfy  V  < 

V*,  V  <  V,  and  W>  <  V,  for  all  i,j  with  k  >  j  >  i  >  1. 
A  spear  is  illustrated  in  Figure  1. 


Figure  1:  A  k-barbed  flshspear. 

Five  primitive  operations  can  be  performed  on  the 

data  structure: 

PMERGE:  Assumes  W*  is  non-empty.  Performs  a  “par¬ 
tial  merge”  of  Vk  with  Wk  by  comparing  the  first 
element  in  Wk  with  the  first  element  in  Vk  and 
appending  the  smaller  one  to  U.  (If  Vk  is  empty, 
the  first  element  of  Wk  is  appended  to  (/.) 

BARB-MERGE:  Assumes  k  >  1  and  W*  is  empty. 
Merges  14  into  14-i,  and  sets  k  :=  k  -  l.  The 
result  is  a  {k  -  1  (-barbed  fishspear. 

TOP-CAT:  Assumes  k  =  1  and  W\  is  empty.  Appends 
V|  to  U  and  sets  k  :=  0.  The  result  is  a  0> 
barbed  fishspear  (i.e.  the  entire  queue  is  sorted 
and  resides  in  U). 

BARB-CREATE(.Y):  Creates  a  new  segment  14+i  ini* 
tialized  to  X.  Sets  W4+i  :=  U,  U  :=  NIL,  and 
k  :»  It  + 1.  The  result  is  a  (fc  +  l)-barbed  fishs¬ 
pear. 


DELETE-SHARP:  Assumes  U  b  non-empty.  Deletes 
and  returns  the  leftmost  (i.e.  smallest)  element 
otU. 

In  addition  to  the  above,  we  assume  the  exbtence  of 
basic  operations  for  testing  and  comparing  the  lengths 
of  the  various  segments. 

The  priority  queue  operation  EMPTY?  b  imple¬ 
mented  by  testing  if  all  of  the  fishspear  segments  are 
empty,  and  MAKEEMPTY  can  be  defined  in  terms  of 
EMPTY?  and  DELETE -MIN.  To  do  INSERT  (x),  one 
merely  performs  BARB-CREATE({2})  on  the  fishspear 
data  structure.  To  do  DELETE -MIN,  an  application  of 
DELETE  .SHARP  suffices,  provided  that  U  is  non-empty. 
The  following  algorithm  b  a  lazy  approach  to  making 
sure  U  b  non-empty: 

HU  b  empty  then  begin 
while  k  >  1  and  Wk  b  empty  do  BARB-MERGE; 
if  Wk  b  non-empty 
then  PMERGE 
else  TOP -CAT 
end 

Performing  thb  code  before  every  DELETE  .MIN  oper¬ 
ation  will  result  in  a  correct,  albeit  inefficient,  priority 
qnene  algorithm. 

It  b  easy  to  construct  examples  which  cause  the 
above  code  to  make  Q(n2)  comparisons  on  an  n- 
element  input  sequence.  For  example,  such  behavior 
results  on  any  sequence  of  n  insertions  followed  by 
n  DELETE -MIN  operations.  The  n  insertions  produce 
an  n-fishspear  with  one  element  in  each  barb  and  an 
empty  shaft.  At  the  time  of  the  first  DELETE  _MIN,  the 
above  code  combines  all  n  barbs  in  a  series  of  unbal¬ 
anced  merges  requiring  0(n3)  comparisons. 

3.2  A  Particular  Algorithm 

The  strategy  of  our  algorithm  b  to  selectively  per¬ 
form  PMERGE,  BARB -MERGE  and  TOP-CAT  operations 
before  each  priority  queue  operation  so  as  to  maintain 
a  kind  of  balance  on  the  sites  of  the  various  segments 
of  the  fishspear.  Exactly  what  kind  of  balance  our 
algorithm  actually  achieves  b  unclear.  Through  an  in¬ 
volved  analysb,  we  provide  a  good  upper  bound  on  the 
total  number  of  comparisons,  but  we  have  been  unable 
to  obtain  a  simple  inductive  condition  on  the  fishs¬ 
pear  which  our  algorithm  preserves  and  from  which 
our  bound  follows. 

Because  of  the  stack-like  quality  of  the  fishspear,  it 
b  natural  to  present  our  algorithm  recursively.  How¬ 
ever,  it  b  not  the  queue  operations  such  as  INSERT  and 


DELETE -MIN  that  are  defined  recursively  but  rather  a 
process  Q  which  runs  autonomously,  alternately  mas¬ 
saging  the  fishspear  and  processing  priority-queue  op¬ 
erations.  In  other  words,  we  regard  Q  as  a  black  box 
to  which  we  send  priority  queue  operations  to  be  per¬ 
formed  and  which  sends  answers  back  to  us  in  response 
to  those  operations.  Q  is  separate  from  the  “user*  pro¬ 
cess  which  is  issuing  the  priority  queue  operations,  al¬ 
though  Q  could  be  implemented  as  a  coroutine  just  as 
well.  This  view  is  illustrated  in  Figure  2. 


Figure  2:  Process  structure  of  the  Fishspear  algorithm. 

We  assume  two  synchronized  primitives  for  interpro¬ 
cess  communication,  SEND(m)  and  RECEIVE,  where  m 
is  a  message.  (Cf.  CSP  |2j.)  A  process  executing 
RECEIVE  blocks  until  the  other  process  is  ready  to  exe¬ 
cute  SEND(m)  for  some  m,  at  which  time  the  RECEIVE 
operation  returns  m  as  its  value  and  both  processes 
continue.  Similarly,  a  process  executing  SEND(m)  is 
forced  to  wait  until  the  other  process  is  ready  to  exe¬ 
cute  RECEIVE. 

Messages  are  elements  of  D  U  {‘del", 'empty?'}  u 
{‘yes', 'no'}.  A  message  in  D  denotes  an  element  to 
be  inserted,  if  sent  by  the  user  process,  or  the  mini¬ 
mum  element  just  deleted  from  the  queue,  if  sent  by 
Q.  Messages  del'  and  'empty?'  are  requests  by  the  user 
process  to  perform  a  DELETE _MIN  or  EMPTY?  opera¬ 
tion  on  the  priority  queue,  ‘yes'  and  no’  are  responses 
by  Q  to  the  ‘empty?’  request.  We  assume  the  user 
process  performs  RECEIVE  immediately  following  each 
SEND( 'empty?')  and  SEND('del')  request  in  order  to  re¬ 
ceive  the  response. 

Q  maintains  two  pieces  of  global  data — an  integer  k 
and  a  Jfc-fishspear  stored  in  variables  U,  V,,  and  W,, 
j  >  0.  as  described  above.  All  of  the  manipulations  of 
this  data  are  performed  by  the  five  fishspear  primitives, 
which  are  invoked  by  Q. 

The  heart  of  the  algorithm  is  the  recursive  procedure 

S.  When  S  is  called,  U  is  assumed  to  be  non-empty. 
S  performs  one  or  more  RECEIVE  operations,  carries 
out  the  actions  specified  by  the  messages  received,  re¬ 
sponds  to  each  'del'  or  'empty?'  request  by  issuing  an 
a  SEND  with  the  answer,  and  modifies  the  fishspear 
to  reflect  the  changes  in  the  queue  contents.  When  S 
eventually  returns,  the  length  k  of  the  fishspear  is  one 
greater  than  when  it  was  called,  and  W*  =  $. 

The  code  for  S  is  given  in  Figure  3.  $  is  a  tuning 


parameter.  We  are  able  to  prove  the  best  worst-case 
bounds  for  $  =  0.7034...,  but  any  value  between  0 
and  1  yields  a  correct  algorithm.  In  this  program,  and 
elsewhere  in  this  paper,  we  follow  the  convention  that 
segments  and  sets  are  named  by  upper  case  letters  and 
their  cardinalities  are  denoted  by  the  corresponding 
tower  case  letter.  Thus,  u  denotes  the  length  of  U,  etc. 


Procedure  S: 

1.  u*  :=  u 

2.  BASE 

3.  while  wt  >  0  do 

4.  if  >  u  or  u  >  $ua  then  PMERGE 

5.  else  {vs  <  u}  begin 

6.  S;  BARB-MERGE 

7.  end 

Figure  3:  The  recursive  procedure  S. 

The  actual  processing  of  messages  takes  place  in  the 
routine  BASE,  which  is  given  in  Figure  4.  When  BASE 
is  called,  U  is  assumed  to  be  non-empty.  BASE  pro¬ 
cesses  messages  until  either  a  new  element  is  inserted 
into  the  queue  or  V  becomes  empty.  In  either  case, 
BASE  calls  BARB-CREATE  just  before  returning,  so  the 
resulting  fishspear  is  one  longer  than  at  the  time  of  call. 


Procedure  BASE: 

1.  repeat 

2.  X  :=  RECEIVE 

3.  if  *  =  'empty?'  then  SEND  'no' 

4.  else  if  x  m  del'  then  SEND  DELETE  JSH ARP 

5.  until  z  €  D  or  u  =  0 

6.  if  z  €  D  then  BARB _CREATE( {z}) 

7.  else  BARB.CREATE(0) 

Figure  4:  Code  to  process  queue  operations. 

Finally,  we  give  the  top-level  code  for  process  Q 
which  runs  the  priority  queue  algorithm  by  repeatedly 
calling  S.  Since  S  can  only  be  called  when  the  fishspear 
is  non-empty,  Q  itself  reads  and  processes  messages 
whenever  the  queue  is  empty. 

4  Complexity  Analysis 

We  present  an  upper  bound  on  the  worst-case  num¬ 
ber  of  comparisons,  Comp(nt),  made  by  fishspear  on 
an  input  sequence  with  max-depth  profile  m. 
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Process  Q: 

1.  *  :=  0;  V  :=  I 

2.  repeat  forever 

3.  If  s  =  0  then  begin 

4.  X  :=  RECEIVE 

5.  if  *  a  ‘empty?'  then  send  ‘yes' 

6.  else  if  x  =  ‘del*  then  error 

7.  else  BARB_CREATE({x}) 

8.  end 

9.  else  begin 

10.  S 

11.  end 

12.  TOP -CAT 

Figure  5:  The  top-level  driver. 

Theorem  3  For  all  0,  0  <  0  <  1,  there  exist  c,  cf 
tuch  that  for  all  rune  with  n  intertioni  and  max-depth 
profile  m, 

W 

Comp(m)  <  c  ^2  logm<  +  c'n. 

•=1 

In  particular,  for  0  =  .7034,  we  may  take  c  *  2.4. 
(Further  detail*  on  the  interdependence  of  c,  cf  and  0 
are  given  in  the  anatysis  below.) 

The  proof  consists  of  several  parts.  First,  we  clas¬ 
sify  each  comparison  made  by  the  algorithm  as  being  of 
Type  I  or  Type  II,  and  we  observe  that  at  most  n  Type 
I  comparisons  are  made  in  the  course  of  the  algorithm. 
We  analyte  the  number  of  Type  II  comparisons  by  set¬ 
ting  up  a  toll  “economy”  in  which  tolls  are  charged  to 
queue  elements  at  various  points  in  the  algorithm  and 
are  used  to  pay  for  comparisons.  The  tolls  collected 
are  sufficient  to  pay  for  all  the  Type  II  comparisons, 
and  each  element  is  charged  only  elogm,  +  c"  tolls. 
Summing  over  all  the  elements  gives 

#  Type  II  comparisons  <  tolls  collected 

<  c£logm,+  c"n. 

The  theorem  then  follows  by  summing  the  upper 
bounds  for  the  two  types  of  comparisons  and  taking 
e  =  +  i. 

4.1  Comparison  Types 

A  comparison  which  results  in  an  element  first  en¬ 
tering  the  shaft  of  the  fishspear  is  of  Type  I;  all  other 
comparisons  are  Type  11.  An  examination  of  the  algo¬ 
rithm  shows  that  there  are  only  two  places  in  which  ele¬ 
ments  are  compared:  within  the  PMERGE  of  line  4  of  S, 


and  within  the  BARB  .MERGE  of  line  6  of  S.  PMERGE 
compares  the  first  element  of  Ft  with  the  first  element 
of  Wit  and  appends  the  smaller  (higher  priority)  to  U. 
Thus,  that  comparison  is  of  Type  I  if  the  smaller  ele¬ 
ment  came  from  V*  and  is  of  Type  II  if  the  smaller 
element  came  from  Wk.  All  comparisons  made  by 
BARB-MERGE  are  of  Type  II,  since  no  elements  enter 
the  shaft. 

Lemma  1  The  algorithm  make s  at  most  n  Type  l 
comparisons. 

Proof:  Once  an  element  enters  the  shaft,  it  remains 
there  until  eventually  deleted  from  the  queue.  Hence, 
at  most  n  Type  I  comparisons  are  made  in  the  course 
of  the  algorithm  since  each  element  enters  the  shaft 
only  once.  I 

4.2  The  Progress  Lemma 

We  now  take  a  more  detailed  look  at  the  recursive 
structure  of  the  algorithm  and  the  actions  which  it  per¬ 
forms.  We  first  introduce  some  notation  to  allow  us  to 
talk  about  the  way  the  fishspear  changes  over  time.  At 
any  time  r,  let  UT  be  the  set  of  elements  in  segment  V , 
let  VT  be  the  set  of  elements  in  segment  V*,  let  Vf  be 
the  set  of  elements  in  segment  V*..,,  assuming  k  >  1 
at  that  time,  and  let  WT  be  the  set  of  elements  in  Wk. 
These  definitions  depend  on  the  current  value  of  k,  so 
in  particular,  Vr  always  refers  to  the  top  barb  of  the 
fishspear,  and  V)  always  refers  to  the  second-from-top 
barb.  As  usual,  the  corresponding  lower  case  letter 
refers  to  the  cardinality  of  the  set,  so  uT  =  jf/r|,  etc. 

Now  consider  a  single  instance  of  a  call  on  S  and  the 
computation  that  takes  place  between  the  time  a  of  the 
call  and  the  time  u  of  the  return.  Let  a'  be  the  time 
just  before  line  3  of  S  is  executed  for  the  first  time,  and 
let  r  be  a  time  at  which  control  is  between  lines  of  S 
such  that  a'  <  r  <  u/.  We  define  the  following  sets  of 
elements: 

I Nr  =  set  of  elements  inserted  into  the 
queue  after  time  a  and  still  present 
in  the  queue  at  time  r; 

OUTr  =  set  of  elements  present  in  the  queue 
at  time  a  but  gone  from  tVe  queue 
by  time  r; 

V*u  •  Vr  n  Va,  the  set  of  old  elements  in 
V  at  time  r; 

U*,m  =  Vr  n  INt,  the  set  of  new  elements 
in  V  at  time  r. 

We  often  omit  the  subscript  r  when  r  is  clear  from 
context.  The  relationships  that  exist  among  these  sets 


are  given  in  Figure  6  and  are  easily  proved  by  induction 
on  r,  for  r  between  a'  and  u. 


U 


Figure  6:  Relations  among  the  basic  sets  after  time  a'. 

Lemma  2  (Progress  Lemma )  Let  t  be  any  time,  a'  < 
r  <  w,  such  that  the  test  u  >  0ua  in  line  4  of  S  has 
never  evaluated  to  irue'  anytime  during  the  interval 
from  a'  to  r,  and  control  is  between  lines  of  S.  Then 

Vr  >  ttrW  ~  I- 

Proof:  To  begin  with,  observe  that  if  the  condition 
u  >  dua  once  becomes  true,  then  it  remains  true  for 
the  duration  of  that  execution  of  S,  for  as  long  as  it 
is  true,  the  ‘then’  branch  of  the  condition  in  line  4  is 
always  taken,  and  PMERGE  does  not  change  ua  nor 
decrease  u. 

We  proceed  to  prove  the  lemma.  At  time  r  =  a', 
U  is  empty,  so  u°ld  =  0  and  the  lemma  holds.  Subse¬ 
quently,  the  only  places  where  V  or  V  are  modified  are 
in  lines  4  and  6  of  S.  We  consider  them  in  turn. 

Suppose  r  is  a  time  just  after  the  PMERGE  in  line  4 
of  S  has  been  performed,  and  suppose  the  conditions  of 
the  lemma  are  satisfied  at  time  r.  Then  uT  <  0ua,  so 
v  >  a  >  u0,d  just  before  the  PMERGE.  The  PMERGE 
moves  one  element  from  either  V*  or  W*  into  U.  If  it 
moves  an  element  from  V*,  then  v  decreases  by  1  but 
uold  remains  unchanged  (since  V*  consists  entirely  of 
new  elements).  If  it  moves  an  element  from  W then 
uold  increases  by  1  but  v  remains  unchanged.  In  either 
case,  v  >  uold  —  1  afterwards. 

Now  consider  the  effect  of  line  6  on  U  and  V.  The  re¬ 
cursive  call  on  S  modifies  U  and  adds  a  new  barb  to  the 
fishspear.  The  call  on  BARB  .MERGE  then  merges  the 
top  two  barbs  together,  leaving  the  fishspear  with  the 
same  number  of  segments  as  it  had  before  the  recursive 
call.  Line  6  can  only  decrease  (or  leave  unchanged)  the 
size  otUM,  tor  the  segment  U  immediately  after  the 
recursive  call  consists  entirely  of  elements  that  were 
in  U  just  before  the  call  together  with  new  elements 
(that  is,  elements  inserted  into  the  queue  during  the 
recursive  call),  and  BARB -MERGE  does  not  affect  U. 
Line  6  can  only  increase  (or  leave  unchanged)  the  size 
of  V,  for  its  overall  effect  is  to  add  to  V  those  elements 
which  the  recursive  call  on  S  placed  in  the  new  barb, 


and  these  are  all  new  elements  inserted  during  the  re¬ 
cursive  call  Hence,  lines  6  preserves  the  truth  of  the 
conclusion  of  the  lemma.  The  lemma  then  follows  by 
induction.  I 

The  following  is  a  direct  consequence  of  the  Progress 
Lemma. 

Lemma  3  For  any  execution  of  S,  either 
inu  +  oatu,  >  u„  -  l 
or 

inu  >  0ua  -  1. 

Proof:  There  are  two  cases,  depending  on  whether  the 
test  u  >  0ua  in  line  4  of  S  ever  evaluated  to  ‘true’. 
Case  1:  The  test  never  evaluated  to  ‘true’.  Then  by 
Lemma  2,  vu  >  u°ld  - 1.  Also,  tv„  =  0  since  the  ‘while’ 
loop  of  line  3  terminated.  Thus,  using  Figure  6.  we  see 
that  tnu  =  «*•"  +  vu  and  outu  =  u„  -  u°ld.  Hence, 

»nu  +  outu  >  ua  +  u  “*w  -  1 
>  ua  -  1. 

Case  2:  The  test  first  evaluated  ‘true’  in  an  execution 
of  line  4  which  began  at  time  r.  Then  by  Lemma  2, 
tV  >  u“ld  -  1.  From  time  r  to  w,  only  PMERGE 's  are 
done,  and  no  elements  are  deleted  from  the  queue,  so 

inu  =  u"*w  +  fu  =  u"ew  +  vT. 

Hence, 

inu  >  urn,w  +  urold  -  1  =  uT  -  1, 

Since  the  test  was  about  to  evaluate  ‘true’,  we  have 
»r  >  so 


4.3  The  Toll  Economy 

We  now  describe  our  method  of  analyzing  the  num¬ 
ber  of  Type  II  comparisons.  We  associate  with  each 
element  inserted  into  the  queue  two  infinite  sets  of  to¬ 
kens,  the  in-tokens  and  the  out-tokens.  The  tokens  in 
each  set  are  numbered  sequentially  beginning  with  1. 
In  addition,  each  element  has  two  base-tokens.  The 
value  of  in-token  (out-token)  number  d  is  t\/d  (to/d), 
and  the  value  of  the  base  token  is  ta,  where  ti,  to,  and 
fn  are  positive  constants  to  be  specified  later.  They 
will  depend  on  a  parameter  6  which  can  be  chosen  ar¬ 
bitrarily  from  the  open  interval  (0, 0/2). 


We  collect  tolls  by  removing  tokens  from  elements 
that  are  or  were  in  the  queue.  The  tolls  collected  T  is 
the  total  value  of  all  tokens  so  taken.  We  ensure  that 
any  in-tokens  and  out-tokens  taken  satisfy  the  follow¬ 
ing: 

Tolling  Rule  The  number  p  of  the  high¬ 
est  numbered  token  collected  from  any 
element  x*  satisfies  p  <  (mi  +  1  )/S. 

We  remark  that  for  any  set  X  of  elements  simultane¬ 
ously  present  in  the  queue  and  still  possessing  token 
p,  the  Tolling  Rule  lets  us  collect  token  p  from  all  but 
|£pj  -  1  elements  of  .Y,  for  those  elements  all  have 
depth  at  least  [£pj  >  6p  -  1. 

Lemma  4  Any  manner  of  collecting  tolls  according  to 
the  Tolling  Rule  results  in 

T  <  2 ta  +  (£]  +  to )  53  In  mi  +  ^ln  —  ^  •  rcj , 

where  In  x  denotes  the  natural  logarithm  of  x. 

Proof:  Since  the  largest  token  allowed  by  the  tolling 
rule  is  at  most  [(mi  +  l)/£j,  we  have 

n  l(n*i+l)/SJ  J 

T  <  2fB  +  (li  +to)£  £3  i 

i=l  4=1 

<  2tn  +  (t|  +  tp)  ^3  f  1  +  In  — j ^ 

i=i  '  ' 

W  j  rt  j 

since  7  -  <  1  +  /  -  dz  =  1  +  ln  t 

Ji  z 

<  2 te  +  (ti  +  to)  53 In  ~y~ 

1=1 

=  2tB  +  (*i +*o)  j  +  (ln  7)  '  nj  • 


Fix  a  run  of  the  queue.  We  will  associate  each  to¬ 
ken  collected  with  a  particular  execution  of  S.  Before 
describing  exactly  how  this  is  done,  we  introduce  a  no¬ 
tation  for  naming  such  executions. 

We  define  S„  inductively  for  certain  strings  a  of  pos¬ 
itive  integers.  Let »'  >  1.  Si  denotes  the  execution  of 
S  which  results  from  the  Ith  execution  of  line  10  of  the 
top-level  program  Q,  assuming  Q  executes  line  10  at 
least  •  times  in  the  run,  and  otherwise  Si  is  undefined. 


Inductively,  suppose  a  is  a  string  of  natural  numbers, 
and  suppose  S,  denotes  an.  execution  of  S  which  per¬ 
forms  line  6  a  total  of  r  times.  Then  S**  denotes  the 
execution  of  S  which  results  from  the  Ith  execution  of 
line  6  by  S„,  1  <  «  <  r.  S at  is  undefined  if  i  >  r  or  if 
S0  is  undefined.  Also,  St  is  undefined,  where  e  denotes 
the  empty  string. 

Let  a(<r)  and  w(<r)  denote  the  endpoints  of  the  time 
interval  spanned  by  the  execution  Sa.  The  interval  of 
Sa  contains  in  the  interval  of  S„>  if  0  is  a  prefix  of  o', 
and  the  intervals  are  disjoint  if  neither  <7  nor  o'  is  a 
prefix  of  the  other. 

S„  is  eligible  to  accept  a  token  t  if  the  following  con¬ 
ditions  bold: 

•  t  is  a  base  token  of  element  Xj,  and  x:  was  in¬ 
serted  or  deleted  during  the  interval  spanned  by 
So- 

•  t  is  in-token  number  p  of  element  x, ,  x,  was  in¬ 
serted  into  the  queue  during  the  interval  spanned 
by  So,  and  p  <  min{ua(ff),  (m,  +  l)/f}. 

•  t  is  out-token  number  p  of  element  x,,  x, 
was  deleted  from  the  queue  during  the  interval 
spanned  by  S„,  and  p  <  min{ua(9),(m,  +  l)/6}. 

We  associate  t  with  the  lowest  level  execution  which 
is  eligible  to  accept  it,  that  is,  among  the  executions 
S*  eligible  to  accept  t,  we  associate  t  with  the  one  for 
which  the  length  of  o  is  maximal.  That  this  is  unique 
follows  from  the  fact  that  two  distinct  strings  of  the 
same  length  describe  non-overlapping  executions.  If  t 
is  associated  with  S„,  we  say  that  t  is  collected  by  S„, 
or  that  v  tolls  are  taken  by  S„,  where  v  is  the  value  of 
(  as  defined  above. 

Looked  at  from  another  perspective,  the  following 
tokens  are  collected  by  S„  if  permitted  by  the  Tolling 
Rule: 

•  A  base  token  from  whatever  element  was  inserted 
or  deleted  from  the  queue  by  the  execution  of 
BASE  in  line  2  of  S„. 

•  In-tokens  u0(„,)  through  ua{a)  -  1  of  element  x 
if  x  was  inserted  in  the  queue  during  the  ith  ex¬ 
ecution  of  line  6  of  S„. 

•  Out-tokens  ua(<rt)  through  -  1  of  element 
x  if  x  was  deleted  from  the  queue  during  the  Ith 
execution  of  line  6  of  S*. 

This  characterization  holds  because  we  assume  0  <  1, 
so  the  test  in  line  4  of  S  then  ensures  that  < 

■!„((,).  Thus,  if  p  >  Ua(ffi),  it  follows  inductively  that 


Sai7  is  not  eligible  to  collect  any  token  number  p  for 
any  string  7. 

In  the  remainder  of  this  section,  we  assume  that 
6,0  €  (0,1),  6  <  0/2,  and  that  t{,to,«i,fo.tB 
positive  constants  which  satisfy  the  following: 

«{?-(‘5?  +  <o(l  -?))lBfl-2-g>0  (2) 

holds  if  0  <  q  <  0. 

■!  *  » 

s  <1 2 * 4> 

tB  >  t|(l-5).  (5) 

Let  T(o)  be  the  total  value  of  all  tokens  collected  by 
Sff.  We  now  derive  a  lower  bound  on  T(<r). 

Lemma  5  (Tolls  Lemma).  Let  S„  be  an  execution  of 
S,  and  let  a  =  a(a)  and  ui  —  w(o).  Then 

T(ff)  >  2 ua  +  uu. 

Proof:  Consider  the  times  a(<7«),  i  =  1,2,...  inline- 
diately  preceding  the  successive  executions  of  line  € 
during  the  while-loop  of  S.  Let  /<i  =  or(<rl)  and  let 
Hr+i  =  a(<ri)  where  i  is  the  least  number  such  that 
S„,  is  defined  and  ua(<ri)  >  u„,.  Finally,  let  <  be  the 
largest  index  for  which  p,  is  defined.  As  a  notational 
convenience,  we  write  (j)  for  Pj. 

Each  of  INU,  and  OUTu  are  sets  of  elements 

which  are  simultaneously  in  the  queue — the  elements 
of  IN(j)  are  all  present  at  time  p},  the  elements  of  INU 
are  all  there  at  time  w,  and  the  elements  of  OUTu  were 
all  in  the  queue  at  time  a.  By  the  remark  following  the 
Tolling  Rule,  we  can  collect  in-token  number  p  from  all 
but  [6p\  -  1  of  the  elements  in  IN{,)  or  INU.  Similarly, 
we  can  collect  out-token  p  from  all  but  |5pJ  -  1  of  the 
elements  of  OUTu. 

We  now  total  up  the  tokens  we  know  are  collected 
by  S„,  thereby  giving  a  lower  bound  on  T(<t). 

1.  At  least  one  base  token  is  collected  by  S„  since 
the  call  on  BASE  in  line  2  of  S  causes  at  least  one 
element  to  be  inserted  or  deleted.  It  has  value 

T,(<r)  =  fB.  (6) 


number  p  is  collected  from  all  but  |5p]  -  1  of 
the  elements  in  INy)  for  a  total  value  of  at  least 
(Sp— I))/p.  Summing  over  j  andpgives 
a  total  value  of 

*  •<i)—t  . 

r2(*)  =  £  £  t,(,n0)-(«p-l))i  (7) 

J=1  »=«(/-!)  P 

3.  Let  <  p  <  ua  -  1.  By  the  remark  following 

the  Tolling  Rule,  in-token  p  is  collected  from  all 
but  |5pJ  -  1  of  the  elements  in  u  I Nu  for 

a  total  value  of  at  least 

7s(<r)  =  E  fi(max{«n(,),tnw}  -  (6p  -  1)) - 

*=■<•>  P 

(8) 

4.  Let  U(,)  <  p  <  ua  -  1.  By  the  remark  following 
the  Tolling  Rule,  out-token  p  is  collected  from  all 
but  |£pj  -  1  of  the  elements  in  OUTu  for  a  total 
value  of  at  least 

•«-i  . 

r«(*)=  E  to(outu-[6p-l))-  (9) 
*=■<*>  P 

Thus,  T(<t)  >  EUi 

By  Lemma  2  and  Figure  6,  in^  >  -  1.  Since 

also  U(;)  >  p  in  the  summation.  Equation  7  yields 

«  «'/)->  . 

W>EMi-%0>  E  ;■  no) 

3= 1  r=»i>-i)  P 

Using  the  fact  that 

j 

tt<»  Up-  UW  “  “U-D’ 

p=«o-D  y 

we  in  turn  get 

# 

TMff)  >  -*)(«(»  -«fy-l>) 

3= I 

=  «l(l  -*)(«(.,  -1)  (11) 

By  Lemma  2  and  Figure  6,  in^  >  u(>)  -  1,  and 
by  Lemma  3,  we  have  0ua  <  inu  +  outu  +  1  < 
max{u(,),  inu  +  1)  +  outu  4- 1.  Using  the  fact  that 

1 

r  »(.) 


2.  Let  1  <  j  <  s  and  let  u^_i)  <  p  <  uy)  -  1.  (For 

technical  convenience,  we  take  U(0)  =  1.)  By 

the  remark  following  the  Tolling  Rule,  in-token 


(12) 


Equation  8  then  yields 


>  2ua  +  vu. 


Ts(o)  >  t|(max{in<.),«nu}-(5u0 -1))  - 

s=»<«)  P 

>  jtj  max{u(,),  inu  +  1} 

-ti|(max{u(#),inw  +  1}) 

-t4(outw  +  l)lln— .  (13) 

P  *  «{*) 

Also,  Equation  9  yields 

*•  , 

Ti(o)  >  t0(outu  -  (6ua  -  l))  £  i 

s=«u>  P 

>  +  1) 

-<o|(max{tt(,),inw  + 1}) 
~t0^(outu  +  1)|  in  — .  (14) 

Combining  Equations  13  and  14  with  3  and  4,  we  get 

T,(<r)  +  r«(<T) 

>  [e>  (l  “  il^i-ti2ljniax.(uj,)linu  +  1} 

>  (t{  max{it(,),inu  +  1} 

+  f'o(oulu  +  l)|ln^  (15) 

From  Equation  3,  we  have  ( 1  —  5)  >  t|.  Thus, 
adding  together  Equations  6,  11,  and  15,  and  using 
Equation  5,  we  get 


T(<r) 


Let 


u/,>  tnu  + 1  ,  outu 

=  -X-L,  a  = - ,  and  r  = - . 

ua  ua  ua 


and  define 


F  =  t\p-  [tj  max(p,  g)  +  £orj  In  p  -  2  -  q. 

It  suffices  to  show  F  >  0  since  inu  +  1  >  vu. 

We  make  use  of  two  constraints  on  p,  q ,  r.  First  of 
all,  the  test  in  line  4  of  S  ensures  that  ti(,)  <  0ua,  so 
p  <  0.  Secondly,  Lemma  3  implies  that  either  q+r  >  1 
or  q  >  0. 

Before  proceeding,  consider  the  partial  derivative 
when  p  <  q: 


d£ 

dp 


£i  ~l£,|9  +  tor)~ 


0. 


This  shows  that  F  decreases  as  p  increases  to  q. 

We  now  consider  three  cases  depending  on  how  q 
relates  to  p  and  0. 

Case  1:  q<p<  0.  Then  ?  +  r  >  1,  so  r  >  \-q  >  1-p. 
Also,  p  <  1  since  0  <  1,  so  In  p  <  0.  Hence, 

F  =  t\p~  (f{p  +  tor|  In  p  -  2  —  ? 

>  «ip-[t{p  +  to(l-p)llnp-2-p. 

By  Equation  2,  F  >  0  as  desired. 

Case  2:  p  <  q  <  0.  Again  r  >  1  -  q.  Since  the  partial 
derivative  of  F  with  respect  to  p  is  negative,  we  can 
replace  p  by  q  to  get 

F  *  *!?-(*!?  +  <or|lnp-2-? 

>  f{?  -  |<{?  +  £o(l  “  ?)|ln?  -  2  -  q. 


>  tB  +  £l(l  -«)(«<.)  -1) 

+|(J  max{u(f),  inu  +  1)  +  t'0(outu  +  1»  In  — 

“<•) 

>  «!«(,)  +  [t|  max{u(t),  inu  +  1) 

+  £ooutw|ln  (16) 

To  complete  the  proof  of  the  lemma,  we  show  that 

*!“<•)  +  (£i  max{u(,),inw  +  1}  +  t'0outu)\a  — 

“<•) 


Again,  Equation  2  gives  F  >  0  as  desired. 

Case  3:  p  <  0  <  q.  Again  the  partial  derivative  of  F 
with  respect  to  p  is  negative,  so  we  can  replace  p  by  0 
and  r  by  0  to  get 

F  -  t\p-\t\q  +  t'0r]\ap-2-q 
>  t\0  -  t\qlo0-2  -q 
=  \t\0  “  2|  -  q[t5  ln/9  +  1|.  (17) 

We  now  consider  two  subcases. 


Subcase  1:  0  >  -2  In  0.  Then  by  Equation  1  we  have 
t{  >  — 1/  In  /J  >  2/0.  Hence, 

F  >  \t\0  —  2}  -  q\t\  In  0  +  1) 

*  [G)H-*[(3)hH 

=  o. 

Subcase  2:  0  <  -2  In  0.  Then  by  Equation  1  we  have 

2  +  0 


<i> 


0(l-ln0)‘ 


Hence, 


^  (2  +  S)lnS  +  S(l-!n/J) 
t',n*  +  l  "  - - 

.  2ln0  +  0 


~  0(1  ~\*0) 
<  0. 


(18) 


Thus,  using  the  assumption  that  0  <  g,  Equations  17 
and  18  give 

r  ^  [2  +  0-2  +  2ln0l  af2ln/9  +  /»l 

F  2  l  (i-i.4r'J'sUi“M)] 

=  o. 

Thus,  in  all  three  cases,  F  >  0,  completing  the  proof 
of  the  lemma.  I 

We  now  relate  the  tolls  collected  to  the  comparisons 
made  by  the  algorithm. 

Let  gain(<r)  =s  T(o)  -  type,7(<r),  where  type/7(o)  b 
the  number  of  Type  II  comparisons  made  by  S*  but 
excluding  comparisons  made  by  the  subrecursive  calls. 

Lemma  6  Let  S„  be  an  execution  of  S,  and  let  a  = 
a(<r)  and  u>  —  u(<r).  Then 

gain(tr)  >  ua  +  vu. 


the  straightforward  way.  Hence,  the  net  gain  of  all  of 
the  executions  of  line  6  is  non-negative. 

We  now  consider  the  PMERGE  in  line  4.  At  most 
ua  Type  II  comparisons  are  made,  since  each  such 
comparison  removes  an  element  from  W*,  and  W*  ini¬ 
tially  (just  after  line  2)  has  size  ua.  By  Lemma  5, 
T(a )  >  2u„  +  vu.  Hence,  gain(o)  >  u0  +  vu  as  desired. 


Putting  all  thb  together  gives  us 

Lemma  7  The  total  number  of  Type  II  comparitont 
made  by  Fiahtpear  on  a  run  with  n  ineertions  and  max- 
depth  profile  m  it  at  mott 


53 1“  m<  +  (in  n 


2  In  +  (t|  +  fo) 


Proof:  The  run  can  be  partitioned  into  segments  of 
operations  which  are  processed  directly  by  Q  and  seg¬ 
ments  which  are  processed  by  a  top-level  call  on  S.  The 
former  require  no  comparisons.  That  the  total  number 
required  for  the  latter  satisfies  the  bound  in  the  lemma 
b  an  immediate  consequence  of  Lemmas  4  and  6.  I 

To  complete  the  proof  of  Theorem  3,  it  b  necessary 
to  analyze  the  constants.  First,  note  that  for  any  6,0  e 

(0,1)  with  6  <  /9/2,  there  exbt  values  of  t0,  (b 

which  satbfy  Equations  1-5.  Use  Equation  1  to  define 
t\.  The  left  hand  side  of  Equation  2  as  a  function 
of  q  b  bounded  from  below  over  the  interval  (0, 0), 
and  as  a  function  of  it  b  linear  with  a  positive 
coefficient  that  b  bounded  away  from  zero.  It  follows 
that  Equation  2  b  satbfied  for  sufficiently  large  t’Q. 
Similarly,  Equations  3  and  4  can  be  satbfied  by  taking 
t|  s  to  sufficiently  large,  for  then  2 6/0  <  1  and  the 
right  hand  sides  are  linear  in  t|  =  to  with  positive 
coefficient.  Finally,  Equation  5  can  be  used  to  define 
tg.  The  constant  c  of  Theorem  3  b  given  by 


c  —  (f j  +  to)  •  In  2, 


(19) 


Proof:  Proof  b  by  reverse  induction  on  the  length  of 
<r,  starting  with  the  longest  words  <r  for  which  S,  b 
defined. 

Suppose  Sv  U  an  execution  of  S  and  the  lemma  has 
been  proved  for  all  executions  with  o  a  proper 
prefix  of  o’.  Consider  the  itk  execution  of  line  6  of 
S  (which  begins  at  time  a(oi)).  The  test  in  line  4 
ensures  va(<ri)  <  uo(<ri).  By  induction,  gain(oi)  > 
«*<*•)  +  Hence,  gain(ot)  >  va{9i)  +  vu{tri).  The 
number  of  comparisons  made  by  BARB  .MERGE  in  line  6 
b  at  most  va(9<)  4-  since  it  simply  merges  to¬ 

gether  the  two  segments  =  Va(9i)  and  in 


and  one  can  take 

.  2e 

C  —  2(g  +  I  +((|  +  (o)'ll  — . 

0 

We  get  our  best  bounds  by  choosing  0  *  -2  In  0  * 
.7034....  Plugging  in  to  Equation  1  yields  t{  « 
2.843....  Calculus  together  with  numerical  evalua¬ 
tion  shows  that  (q  =  .5674...  satisfies  Equation  2, 
and  equality  holds  (to  within  the  limits  of  our  preci¬ 
sion)  for  g  =  .141....  (The  function  of  Equation  2 
over  the  interval  (0, 0)  b  shown  in  Figure  7.)  Thus, 
tj  +  Pq  =  3.410. . ..  By  choosing  6  sufficiently  close  to 


1 


1 


0,  w«  can  make  <i  +  to  arbitrarily  close  to  3.410 _ 

Finally,  plugging  into  Equation  19  shows  that  the  con* 
stant  c  of  Theorem  3  can  be  chosen  arbitrarily  close 
to 

ln(2)  x  3.410...  =2.363.... 

In  particular,  c  =  2.4  works. 


Figure  7:  The  (unction  t|j-(t|g  +  to(l-4))ln?-2-? 
for  t\  =  2.844  and  t'0  =  0.5675. 
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